Computer games and other applications that display a virtual environment often include background scenery to enhance the simulation of the environment. It is common to employ simple color patterns and/or other texture data to represent a terrain or other background surfaces in the environment. The background environment is often repetitively tiled using a relatively limited number of variations. Typically, these simple backgrounds are only two-dimensional (2D), and are not very realistic. However, 2D backgrounds can have much more complex and varied textures and may be designed to be computationally efficient in covering a large area in a simulated virtual environment.
To increase the realism of a simulation, three-dimensional (3D) scenery objects are sometimes used instead of, or in addition to, 2D backgrounds. For example, it is common to include 3D buildings, walls, vegetation, and other scenery objects in computer games. To provide even more realism, a well-known or easily recognized scenery object, such as a landmark or building, may be mapped to a specific location within the simulated environment corresponding to the location of the real object in the environment. Some simulations are thus able to provide very detailed scenery objects in a limited region of the simulated environment, but because of the labor involved, the detail is confined to a relatively small area. For instance, some automobile racing games include very detailed scenery objects that correspond to real buildings, traffic signs, trees, and other objects along some selected streets of cities in which auto races are held, but the remainder of the simulated streets of the cities lack detail and variety.
However, even with foreseeable increases in processor speeds and storage sizes, it is impractical to define, store, and render a scenery object corresponding to each real object over an extended area, such as an entire metropolitan area. The problem becomes even more significant when the simulated environment includes the entire surface of the Earth. Consequently, in prior art simulated virtual environments, 3D scenery objects are often used to simulate specific landmarks in only a few limited areas, while 2D terrain background is typically used in the remaining larger areas of the simulation. For example, as indicated above, it is common to provide 3D simulations of specific landmark buildings in the central portions of a metropolitan area, while using 2D terrain backgrounds in the outskirts.
Clearly, it would generally be desirable to provide more realistic 3D scenery throughout a simulated environment. One method to achieve this result is to pseudo-randomly populate 2D terrain backgrounds with 3D scenery objects that appear realistic, but do not necessarily replicate real objects in the environment. A method to pseudo-randomly generate data for such 3D scenery objects is described in a commonly assigned patent application entitled, “Automatic Scenery Object Generation,” which is filed concurrently. Rendering such automatically generated 3D scenery objects in real time requires a more efficient processing technique than is currently employed for rendering only a relatively few landmarks in limited areas. Landmark objects, or other fixed 3D scenery objects, can be preprocessed for efficient rendering, because their location, size, and other characteristics are known well before rendering is needed.
Similarly, some prior systems utilize a library of fixed 3D scenery objects to randomly populate a scene. Although the location of the objects may be randomly determined, the size, shape, texture, and other characteristics are predetermined. Thus, these library objects can be preprocessed for rendering in a manner similar to that used for landmarks or other fixed objects that are manually created and inserted into a simulated environment.
In contrast, the characteristics of automatically generated scenery objects may not be known unless and until it is determined that the scenery objects should be generated. For example, it is desirable to condition object rendering on whether the object is “within view,” or whether the object will be within view shortly, or whether the object is not viewable due to darkness, or upon other criteria that must be satisfied during execution of the simulation. Further, it would be more efficient and more realistic to only render objects that are within view, and to gradually fade in more objects as they become closer to a user's viewpoint. It would be desirable to have predefined object data, but only render those objects that satisfy criteria appropriate for the current circumstances of the simulation during execution. Similarly, it would be desirable to render objects with realistic lighting depending on current conditions in the simulated environment, including for example, the time of day, season of the year, and regional location of the objects in the simulated environment. To provide scenic variety with automatically generated realistic objects, it will be preferable to pseudo-randomly generate and render 3D scenery objects during execution of a simulation in an efficient manner that does not rely on significant preprocessing.
An important application for such efficient rendering of a simulated environment arises when providing a realistic terrain over which aircraft fly in a flight simulator program. A solution to the problems described above was developed for use in Microsoft Corporation's FLIGHT SIMULATOR 2002™ product, which was released for sale in 2001. Subsequently, others appear to have recognized the value of automatically generating a variety of scenery objects that are related to the underlying 2D terrain texture in a simulated environment and have released similar products. However, these other products do not appear to render scenery objects in a manner that obtains the desired efficiencies described above. For example, a freeware product called TERRAMODELS™, produced by Softlang Software and Allen Kriesman, Inc., reportedly generates scenery objects to populate the background landscape in a flight simulator program called FLY II™, which is sold by Terminal Reality, Inc. However, FLY II™ does not appear to vary the number of objects rendered at various distances from a viewpoint of the user, and does not appear to provide other rendering efficiencies discussed above.